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Governing  Delegation  of  Authority  within  SOA  Environments  Using  KAoS 


Abstract.  Within  the  Department  of  Defense  (DoD),  delegation  of  authority  is  the  act  by  which  a 
commander  transfers  part  of  his  authority  to  a  subordinate  commander  in  order  to  complete  an 
assigned  task  or  carry  out  additional  duties.  Delegation  is  often  limited  to  specific  tasks  or  for 
specific  time  periods  and  is  commonly  governed  by  policies  that  specify  what  may  be  delegated,  to 
whom  it  may  be  delegated,  and  under  what  circumstances  delegation  may  occur.  Policies  may  also 
dictate  if  a  person  may  perform  tasks  for  which  he  has  been  given  the  authority  to  delegate.  KAoS 
is  a  powerful  policy  management  system  whose  policies  are  represented  in  the  Web  Ontology 
Language  (OWL),  a  standard  language  for  semantic  modeling.  We  have  built  a  demonstration 
system,  based  on  scenarios  from  an  air  operations  center,  which  utilizes  KAoS  to  govern 
delegation  of  authority  in  the  context  of  web  service  access  control.  The  KAoS  policy  language  is 
expressive  enough  to  support  both  attribute-  and  role-based  authorization  as  well  as  both  fine¬ 
grained  and  coarse-grained  access  control.  We  discuss  the  architecture  of  our  demonstration 
system,  describe  the  mechanisms  for  authorization  of  delegation  actions  and  web  service  requests, 
and  show  how  KAoS  integrates  with  existing  standards  for  web  service  modeling,  implementation 
and  security. 

1.  Introduction. 

In  this  paper  we  describe  an  architecture  and  demonstration  system  for  policy-based  access 
control  of  Web  services.  Our  architectural  framework  is  derived  from  International  Organization 
for  Standardization  (ISO)  Standard  10181-3  (ITU-T,  1995),  which  defines  an  architectural  model 
for  controlling  access  to  networked  resources.  Web  services  and  access  policies  are  drawn  from 
activities  and  procedures  associated  with  an  Air  Operations  Center  and  a  small  set  of  operational 
scenarios.  These  scenarios  incorporate  realistic  patterns  of  service  invocations  while  exercising 
essential  capabilities  of  access  control  and  delegation  of  authority  within  a  federated  environment. 
Policies  govern  both  Web  service  access  and  delegation  of  authority.  Policies,  which  are  written  in 
OWL  [OWL  2004],  are  defined  and  enforced  by  the  KAoS  policy  services  framework.  Each  policy 
permits  or  denies  access  to  a  Web  service  based  on  credentials.  Some  credentials  accompany  the 
request,  while  others  are  looked  up  based  on  the  requestor’s  identity. 

Central  to  our  governance  approach  is  a  Delegation  Management  Web  service.  This  web  service 
exposes  operations  for  assigning  and  revoking  roles.  Such  roles  infer  subsets  of  credentials 
associated  with  a  specific  delegation  of  authority.  Underlying  these  policies  and  their  supporting 
web  services,  we  have  constructed  a  formal  model  of  delegation-of-authority  as  practiced  in  an  Air 
Operations  Center.  This  model,  which  is  also  written  in  OWL,  was  integrated  with  the  core  KAoS 
policy  ontologies  to  create  semantically  rich  policies  that  enable  fined-grained  control  of  both  Web 
service  access  and  delegation  of  authority. 
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Within  the  DoD,  delegation  of  authority  is  the  act  by  which  a  commander  transfers  part  of  his 
authority  to  a  subordinate  commander  in  order  to  complete  an  assigned  task  or  carry  out 
additional  duties.  Delegation  of  authority  is  often  limited  to  specific  tasks  or  for  specific  time 
periods  and  is  commonly  governed  by  policies  that  specify  what  may  be  delegated,  to  whom  it 
may  be  delegated,  and  under  what  circumstances  delegation  may  occur.  Furthermore,  policies 
may  also  dictate  whether  or  not  a  person  may  perform  tasks  for  which  he  has  been  given  the 
authority  to  delegate.  For  example,  suppose  a  flight  operations  manager  has  been  delegated  the 
authority  to  assign  pilots  to  flights.  A  delegation  policy  should  prevent  the  manager  from  assigning 
himself  to  a  flight  unless  he  is  also  a  pilot. 

Any  recipient  who  is  asked  to  perform  a  service  should  be  able  to  verify  that  the  requestor  has  the 
authority  to  make  such  a  request.  If  the  requestor  has  not  been  properly  authorized,  the  request 
should  be  denied.  Authorization  is  commonly  based  on  presenting  the  recipient  with  a  set  of 
credentials.  Using  this  information  the  recipient  can  decide  if  the  request  should  be  accepted  or 
denied.  Within  the  context  of  delegation,  the  requestor  may  be  a  delegate,  and  the  recipient  would 
also  enforce  the  delegation  policy  of  its  organization  when  considering  service  requests. 

Increasingly,  delegation  of  authority  takes  place  within  a  computing  context.  Managers  may  need 
to  delegate  some  privileges  to  subordinates  to  enable  them  to  carry  out  computer-based  tasks.  In 
an  enterprise  system,  Web  services  themselves  may  need  the  ability  to  delegate  the  ability  to 
invoke  operations  to  other  services.  Service  providers  need  to  be  able  to  verify  that  each  service 
requestor  is  properly  authorized.  If  the  service  requestor  has  received  dynamically-delegated 
authority,  service  providers  need  to  be  able  to  verify  that  this  was  done  in  accordance  with  their 
delegation  policy.  In  addition,  whenever  delegation  of  authority  is  attempted,  there  must  be  a 
mechanism  to  ensure  that  such  delegation  is  permitted. 

In  designing  our  access  control  mechanism,  we  addressed  the  requirements  specified  by  Chadwick 
[Periorellis  2008]  for  a  general  purpose  Delegation  of  Authority  Service  (DoAS).  We  summarize 
these  below.  Since  we  are  already  assuming  that  the  DoAS  is  operating  within  a  Service-Oriented 
Architecture  (SOA),  we  have  omitted  the  last  one. 

1.  The  DoAS  should  be  able  to  support  delegation  from  person  to  person,  person  to  task,  task 
to  task,  and  service  to  service. 

2.  Every  principal  should  authenticate  with  its  own  independent  identity,  enabling  delegation 
to  be  performed  from  one  named  entity  to  another. 

3.  To  support  a  scalable  authorization  infrastructure,  access  controls  should  support 
attribute-  or  role-based,  where  each  principal  is  assigned  an  attribute  set,  and  each  set  of 
attributes  may  be  used  to  grant  selected  access  rights  to  a  given  resource  or  set  of 
resources,  e.g.  Web  service  operations. 
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4.  Principals  should  to  be  able  to  delegate  any  of  their  attributes  to  other  principals.  Such 
delegation  enables  the  delegee  to  perform  additional  tasks  that  are  authorized  through  its 
association  with  the  delegated  attributes. 

5.  The  DoAS  should  embody  a  delegation  policy  along  with  an  enforcement  mechanism  that 
will  control  both  the  delegation  process  itself  and  the  authorization  process  for  the 
requested  Web  service. 

6.  The  DoAS  should  support  fine-grained  delegation,  i.e.  the  ability  to  delegate  authority  to 
access  a  particular  operation  of  a  Web  service  or  perform  a  particular  operation  on  a  data 
resource. 

7.  Users  should  be  able  to  authenticate  and  prove  their  identity  without  having  to  possess  a 
public  key  certificate. 

8.  The  DoAS  should  support  immediate  revocation  of  delegated  attributes,  cutting  short  the 
originally  intended  duration  of  effectivity.  Furthermore,  acts  of  delegation  themselves 
should  take  effect  instantaneously. 

In  the  next  section  we  present  our  architecture  and  discuss  show  how  it  satisfies  these 
requirements. 

2.  Architectural  Framework. 

Our  approach  integrates  technologies  for  semantic  modeling,  Web  service  access  control,  and 
policy  management  within  an  enterprise  environment.  Software  components  are  written  in  Java 
Enterprise  Edition  (EE).  Access  control  and  delegation  management  services  are  implemented  as 
Web  services  that  conform  to  Organization  for  the  Advancement  of  Structured  Information 
Standards  (OASIS)  and  World  Wide  Web  Consortium  (W3C)  standards  including  SOAP,  Web 
Service  Description  Language  (WSDL)  and  Extensible  Markup  Language  (XML).  For 
authentication,  these  services  leverage  existing  Web  Service  (WS)  security  infrastructure  that 
includes  a  variety  of  WS-*  standards  and  specifications.  Semantic  models  and  policies  use  OWL 
and  Resource  Description  Framework  (RDF). 

ISO  Standard  10181-3  (ITU-T,  1995)  defines  an  architectural  model  for  controlling  access  to 
networked  resources  (see  Figure  1).  In  the  ISO  model,  access  control  is  effected  by  two 
components,  the  Policy  Enforcement  Point  (PEP)  and  the  Policy  Decision  Point  (PDP).  The  PEP 
intercepts  incoming  requests  and  asks  the  PDP  if  the  requestor  has  the  authority  to  perform  the 
requested  action  on  the  protected  resource.  The  PDP  maintains  a  set  of  policies  that  define 
necessary  credentials  for  each  type  of  access  for  each  protected  resource.  Based  on  the  applicable 
policy  and  supplied  credentials,  the  PDP  determines  if  the  requester  is  granted  access  to  the 
resource.  It  returns  its  response  to  the  PEP,  which  then  either  grants  or  denies  the  original 
request.  In  this  model,  the  credentials  may  be  provided  with  the  access  request,  or  the  PDP  can 
retrieve  them  from  a  credential  repository  using  the  requester’s  identity. 


3 


User  S  Site 


Target  Site 

AhlF  ]i|Tj, JiuiT  ittn  lL^ioiaLitI 
“ ,  CtiflliOl;  liiLftfrranCrjt 

?FTJ  -Policy  Tjti^r^uirx'ug  Ftnni 


ImiEHiLvr  knbmiE  . 

LC“1L,l!  r-  7ZZ  ”  /Interne  -  -*■ 

Access; 


AEF  PEP 


Kaju^l 


J 

Dcckimn 

R^qu^Ki 


Present 


Access 

Request 


Dectiion 


ADKPDP 


Targel 


ADF-  qjpJ  KiUmik  n  h  liqwn  k^erf 

■\£Ci-wi  l ■: :■ ! tl i <. >1  De^bicMi  RtaLdifin 
3?hlF  tolrcry  I  kciij^i  hlui 


Figure  1.  ISO  Standard  10181-3  Architectural  Model  for  Network  Resource  Access  Control. 

Our  architecture  is  consistent  with  the  ISO  Standard  10181-3  model.  Figure  2  details  components 
relevant  to  both  Web  service  access  control  and  delegation  management. 


Application  Server  Infrastructure 

Application  Server 


Figure  2.  Architecture  for  Policy-Based  Access  Control  and  Delegation  Management. 

2.1  Runtime  Management  of  Delegation  and  Access  Control  Policies. 

Functions  of  the  PEP  and  PDP  are  distributed  among  the  Access  Control  Service  (ACS),  KAoS 
Guard  and  KAoS  Directory  Service  (KDS).  The  ACS  intercepts  each  Web  service  request.  It  extracts 
salient  information  from  the  request  including  the  requestor’s  identity,  Web  service  operation, 
and  any  pertinent  contextual  information.  (Our  architecture  does  not  include  an  authentication 
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component,  but  assumes  authentication  information--at  a  minimum,  the  requestor's  identity--  is 
transmitted  with  each  service  request.)  The  requester’s  identity  is  used  to  query  the  Credentials 
Repository.  The  ACS  then  invokes  the  KAoS  Guard  with  the  supplied  credentials  to  perform  an 
authorization  check.  The  Guard  contains  a  set  of  policies  that  control  access  to  the  hosted  Web 
services.  These  policies  are  maintained  by  the  KDS.  The  KDS  ensures  that  the  Guard  is  configured 
with  the  latest  policy  set  as  policies  may  be  updated  at  any  time.  The  Guard  applies  the  relevant 
policy  against  the  supplied  credentials.  The  request  is  either  authorized  or  denied.  Authorized 
requests  are  forwarded  to  the  appropriate  Web  service.  Within  our  demonstration  system,  these 
web  services  address  Command  and  Control  (C2)  capabilities  relevant  to  air  operations. 

2.2  KAoS  Policy  Framework. 

KAoS  is  the  foundation  of  our  solution  for  policy-based  access  control.  The  KAoS  framework  is  a 
policy  management  system  that  has  sufficient  generality  and  expressive  power  to  span  the 
breadth  of  requirements  for  enterprise  applications  [Uszok  2004,  2008].  A  singular  advantage  of 
KAoS’  OWL-based  policies  is  that  they  can  either  be  used  directly  or,  because  of  their  rich 
semantics,  as  abstract  models  that  can  be  converted  to  special-purpose  policy  language 
representations  as  necessary.  KAoS  has  been  integrated  with  a  variety  of  agent,  robotic,  Web 
services,  Grid  computing  (e.g.,  Globus),  and  traditional  distributed  computing  platforms,  and 
across  a  variety  of  industrial,  military,  and  space  applications.  Particularly  relevant  to  the  SOA 
domain,  KAoS  has  been  successfully  integrated  with  service-oriented  technologies  such  as  JBoss 
and  Spring,  allowing  for  policy-based  control  of  the  interaction  among  web  services. 

KAoS  also  provides  basic  services  for  distributed  computing,  including  message  transport  and 
directory  services.  Because  the  services  are  accessed  through  a  well-defined  Common  Services 
Interface  (CSI),  application  developers  can  selectively  use  subsets  of  its  capabilities  (e.g., 
registration,  transport,  publish-subscribe,  domain  management,  remote  request  forwarding, 
queries)  as  appropriate. 

The  basic  elements  of  the  KAoS  architecture  are  shown  in  Figure  3.  Its  three  layers  of  functionality 
correspond  to  three  different  policy  representations.  The  Human  Interface  Layer  provides 
administrative  tools  to  construct,  edit  and  distribute  KAoS  policies.  The  Policy  Management  Layer 
encodes  OWL  policies  and  manages  policy-related  information  for  further  analysis.  The 
Distributed  Directory  Service  (DDS)  encapsulates  a  set  of  OWL  reasoning  mechanisms  based  on 
two  open  source  components:  Jena  [McBride  2001]  and  Pellet  [Sirin].  The  Policy  Monitoring  and 
Enforcement  Layer  establishes  and  maintains  KAoS  enforcement  components  known  as  Guards. 
Guards  embody  "compiled”  OWL  policies,  a  representation  that  affords  extremely  efficient  run¬ 
time  monitoring  and  enforcement  at  "table  look  up”  speeds.  Because,  apart  from  policy  updates, 
Guards  operate  independently  from  the  rest  of  KAoS,  they  can  be  used  as  small-footprint 
standalone  policy  enforcement  platforms  in  disconnected  operations.  This  representation  also 
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provides  the  grounding  for  abstract  ontology  terms,  connecting  them  to  instances  in  the  runtime 
environment  and  to  other  policy-related  information. 
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Figure  3:  KAoS  Policy  Service  Conceptual  Architecture 

Within  each  of  the  layers,  the  end  user  may  plug  in  specialized  extension  components  if  needed. 
Such  components  are  typically  developed  as  Java  classes  and  described  using  ontology  concepts  in 
the  configuration  file.  They  can  then  be  used  by  KAoS  in  policy  specification,  reasoning  and 
enforcement. 

Policy  negotiation  provides  the  mechanism  for  policy  reconciliation  and  deconfliction  between 
different  nodes/users/applications/groups.  Conflicts  and  ambiguities  may  emerge  for  a  number  of 
reasons  such  actual  differences  in  the  administrative  requirements  of  each  domain,  or  the 
possibility  that  different  regions  of  a  segmented  network  may  independently  learn  conflicting 
policies,  which  have  to  be  reconciled  [and  negotiated)  at  a  later  time  when  connectivity  is  re¬ 
established. 

2.3  Specification  of  Access  Control  and  Delegation  Management  Policies. 

The  KPAT  (KAoS  Policy  Administration  Tool)  graphical  user  interface  allows  end  users  to 
manually  specify,  analyze,  and  modify  authorization  and  obligation  policies  at  runtime.  KPAT 
hides  the  complexity  of  the  OWL  representation  from  users.  The  reasoning  and  representation 
capabilities  of  OWL  are  used  to  full  advantage  to  make  the  process  as  simple  as  possible. 

Whenever  users  are  required  to  provide  an  input,  they  are  presented  with  a  complete  set  of 
context-driven  values  from  which  to  select. 
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KPAT’s  generic  Policy  Editor  presents  an  administrator  with  a  starting  point  for  policy 
construction  -  essentially,  a  very  generic  policy  statement  shown  as  hypertext.  Clicking  on  a 
specific  link  that  represents  a  variable  provides  the  user  with  choices  allowing  him  to  make  a 
more  specific  policy  statement.  During  use,  KPAT  accesses  the  loaded  ontologies  and  provides  the 
user  with  the  list  of  choices,  narrowed  to  the  current  context  of  the  policy  construction.  New 
classes  and  instances  can  also  be  created  from  KPAT.  To  further  simplify  policy  construction, 

KPAT  provides  two  additional  policy  creation  interfaces:  A  Policy  Wizard  to  guide  users  step-by- 
step,  and  a  Policy  Template  Editor  that  allows  custom  policy  editors  for  a  given  kind  of  policy  to  be 
created  by  point-and-click  methods.  For  the  purposes  of  defining  access  control  and  delegation 
management  policies  for  this  project,  we  propose  to  develop  a  specialized  template  editor 
containing  just  the  functionality  required  for  the  use  case  scenarios,  allowing  delegation  policies 
to  be  easily  defined  and  analyzed  by  users  without  requiring  specialized  training. 

2.4.  Delegation  Management  Service. 

The  Delegation  Management  Service  (DMS)  governs  the  process  of  delegation  of  Web  service 
access  privileges.  The  delegator  may  be  a  person  interacting  with  the  DMS  via  a  user  interface  or  a 
software  agent  of  some  kind  (e.g.,  Web  service).  Likewise,  the  role  of  the  delegee  can  be  assumed 
by  either  entity.  This  functionality  fulfills  DoAS  Requirement  1,  as  it  enables  delegation  of 
authority  from  person  to  person,  person  to  software  agent,  software  agent  to  person  or  software 
agent  to  software  agent. 

The  DMS  will  intercept  the  delegator’s  request  and  pass  it  to  the  Guard  to  determine  if  this 
Principal  is  allowed  to  access  the  DMS.  If  the  request  is  granted  then  the  request  is  forwarded  to 
the  DMS.  The  DMS  then  determines  whether  the  delegator  has  sufficient  credentials  to  delegate 
the  specified  attributes  to  the  delegee.  KAoS  policies  determine  what  delegation  of  authority 
actions  can  be  taken  by  specific  requestors  acting  in  particular  roles  or  who  have  been  assigned 
particular  responsibilities.  The  DMS  Guard  will  apply  an  appropriate  delegation  policy.  This 
addresses  DoAS  Requirement  5. 

The  primary  functionality  of  the  DMS  is  to  augment  the  credentials  of  the  specified  delegee  on 
behalf  of  the  delegator,  and  to  publish  the  updated  credentials  into  the  repository.  Afterwards,  the 
delegee  will  be  able  to  use  the  augmented  credentials  to  gain  access  to  the  accompanying 
delegated  services  and  may  be  empowered  to  further  delegate  these  additional  attributes  if 
allowed  by  the  delegation  policy.  Common  representations  for  credentials  include  the  X.509 
attribute  certificate  and  signed  Security  Assertion  Markup  Language  (SAML)  attribute  assertions. 
Periorellis  has  argued  that  the  SAML  format  might  be  more  flexible  [Periorellis  2008b].  To  address 
Requirement  7,  the  credentials  are  digitally  signed  by  the  DMS  [or  related  software  that  actually 
creates  the  new  credentials)  so  that  future  authorization  activities  can  verify  them. 
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Delegation  of  authority  is  seldom  permanent.  The  revocation  of  authority  is  a  challenging  problem. 
The  primary  objective  of  revocation  is  to  remove  a  credential  from  a  delegee  so  that  it  can  no 
longer  be  used  to  gain  access  to  associated  resources.  The  effects  of  revocation  should  be 
instantaneous.  If  this  is  not  feasible,  a  secondary  objective  is  to  inform  resource  providers  that  an 
existing  credential  has  been  revoked.  The  preferred  mechanism  for  the  latter  objective  is  to 
require  providers  to  periodically  check  with  the  credential  issuer. 

Our  revocation  mechanism  follows  that  proposed  by  Chadwick  [Periorellis  2008a].  His  approach 
overcomes  limitations  by  existing  strategies  including  short  lived  credentials  [Tuecke  et  al., 
2004][Alfieri  et  al.,  2005]  [OASIS,  2005]],  credential  revocation  lists  [ITU-T  2005],  and  the  Online 
Certificate  Status  Protocol  (OCSP]  [Myers,  Ankney,  Malpani,  Galperin,  and  Adams,  1999].  In 
Chadwick's  approach,  a  credential  is  issued  just  once  and  stored  in  the  issuer’s  repository  with  its 
own  unique  Uniform  Resource  Locator  [URL).  The  credential  is  then  valid  for  as  long  as  delegation 
is  required  and  can  be  used  many  times  by  many  different  service  providers  without  having  to  be 
reissued.  Revocation  is  simply  and  instantly  achieved  by  simply  deleting  the  credential  from  the 
repository.  Providers  are  required  to  periodically  check  the  presence  of  the  credential  using  the 
URL.  This  period  can  vary  per  application  or  per  request  as  determined  by  the  provider.  Our 
demonstration  system  checks  the  credentials  on  a  per  request  basis  and  assumes  they  remain 
valid  for  the  duration  of  the  request.  The  preferred  manner  for  credential  checking  could  itself  be 
determined  by  policy.  This  revocation  mechanism  satisfies  DoAS  Requirement  8. 

2.5  Domain  and  Policy  Ontologies. 

Our  basic  approach  to  knowledge  capture  is  to  use  a  description  logic  representation  for  domain 
knowledge  expressed  as  OWL  ontologies.  An  ontology  is  a  formal  description  of  concepts, 
relationships,  constraints,  and  axioms  that  exist  for  a  specified  domain  [Gruber  2003].  Unlike  basic 
XML,  which  embodies  semantics  implicitly  and  by  convention,  an  ontology  defines  a  common 
vocabulary  along  with  the  semantics,  and  is  in  a  machine-interpretable  form  to  enable  people  and 
machines  to  reason  about  them.  It  explicitly  states  assumptions  by  clearly  defining  relationships 
between  entities.  An  ontology  has  the  advantage  of  separating  the  domain  knowledge  from  the 
implementation,  such  that  operational  experts  are  able  to  define  the  ontology,  with  minimal 
training  [Noy  and  McGuinness  2001].  A  variety  of  graphical  tools  are  now  available  to  make  the 
process  even  easier. 

Rather  than  construct  a  single  ontology  for  all  of  the  knowledge  in  the  application,  we  chose  to 
work  from  the  key  scenarios  to  arrive  at  a  list  of  important  terms  and  concepts  that  would  form 
the  specific  elements  of  policies.  This  is  supported  by  an  established  foundational  ontology 
(Raytheon's  Hematite™)  and  a  new  'micro-theory'  describing  the  semantics  of  delegation.  The 
micro-theory  approach  to  partitioning  was  pioneered  in  the  Cyc  project  [Cyc]  [CycL]  and  is  used  to 
define  a  particular  area  of  knowledge  in  a  contradiction-free  manner.  We  went  a  bit  further  to 
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sharpen  and  narrow  a  micro-theory  to  a  particular  set  of  inter-related  concepts  forming  a  reusable 
core  within  a  domain  of  analysis. 

With  the  foundational  ontology  and  the  delegation  micro-theory,  we  were  able  to  construct  a 
domain  ontology  that  provides  all  of  the  semantics  needed  to  support  inferencing  and  policy- 
based  reasoning.  While  a  detailed  discussion  of  this  ontology  is  beyond  the  scope  of  this  paper, 
Figure  4  offers  a  relation-focused  concept  map  of  delegation.  Note  that  it  incorporates  concepts 
and  relationships  from  both  the  human-in-the-loop  and  web  service  processes.  Domain-specific 
policies,  such  as  those  used  in  governing  an  Air  Operation  Center,  are  themselves  likewise 
represented  in  an  ontology  within  KAoS  and  edited  with  KPAT. 

2.6  Authentication. 

When  a  requester  desires  access  to  a  Web  service,  the  requester  must  first  be  authenticated.  In 
our  demonstration  system,  user  authentication  (DoAS  Requirement  2]  is  performed  via  a  standard 
login  mechanism  consisting  of  a  username  and  password.  The  architecture  itself  is  agnostic  of  the 
authentication  mechanism  utilized.  Most  likely,  for  operation  within  a  federated  environment,  an 
authenticated  name  will  be  mapped  into  an  authorization  name  (possibly  with  accompanying 
attributes)  and  stored  in  that  user’s  credentials.  We  use  PicketLink  Federation  [PicketLink]  for 
this  purpose.  PicketLink  is  a  JBoss  Community  Project.  The  Federation  subproject  provides 
support  for  Federated  Identity  and  Single  Sign  On.  We  utilize  PicketLink's  Security  Token  Server 
(STS)  to  generate  a  simple  OASIS  SAML  v2.0  token  containing  the  requestor's  identity.  This 
identity  serves  as  the  look-up  key  for  Credentials  when  applying  the  authorization  policies. 
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Figure  4.  A  Micro-theory  of  Delegation:  Relational  View 


3.  Operational  Scenario  and  Demonstration  System. 

Our  operational  scenario  centers  on  the  activities  within  a  notional  Air  Operations  Center  (AOC) 
that  support  target  weaponeering.  Figure  5  details  some  of  the  actions  performed  by  AOC 
personnel  assigned  the  Targeteer  role,  while  Figure  6  does  the  same  for  the  Senior  Offensive  Duty 
Officer  (SODO)  role.  In  this  scenario,  the  Senior  Intelligence  Duty  Officer  (SIDO)  identifies  a  new, 
high-value  targeting  opportunity  [a  bridge).  This  begins  a  chain  of  activities  that  are  carried  out  by 
personnel  acting  in  the  roles  of  Targeteer,  Offensive  Officer,  and  SODO.  These  activities  include 
posting  the  target,  determining  and  selecting  weapons  options,  assessing  collateral  damage, 
formulating  an  Air  Tasking  Order  (ATO)  change,  and  posting  that  change  to  the  current  ATO.  In 
this  scenario,  the  SIDO  and  SODO  are  also  responsible  for  delegating  the  roles  of  Targeteer  and 
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Offensive  Officer  to  personnel  whose  initial  roles  do  not  give  them  authority  to  carry  out  all  the 
required  activities. 


Figure  5.  Targeteer  activities. 


Figure  6.  Senior  Offensive  Duty  Officer  activities. 

To  exercise  our  delegation  of  authority  and  web  service  access  control  mechanisms,  we 
implemented  a  demonstration  system.  The  system  consists  of  four  Java  web  services  to  directly 
support  AOC  actions,  one  Java  web  service  to  handle  delegation  and  revocation  of  authority,  and 
seven  KAoS  policies.  Each  web  service  is  configured  with  the  access  control  service,  which  is 
implemented  as  a  Java  API  for  XML  Web  Services  QAX-WS)  handler.  A  simple  web  application 
initiates  service  requests  through  a  browser  interface.  The  browser  interface  simulates  the 
application  consoles  of  the  various  AOC  personnel.  A  screenshot  of  the  Targeteer’s  weaponeering 
console  is  shown  in  Figure  7. 
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Weaponeering  Console 

-  Target - 1  r~  Weaponeering  Options  Analysis 
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|  BadSelect  | 

Type:  ADA  v 

Desired  Effect  [  DESTROY  v 
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Lat: 
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Weaponeering  Options 
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[  Create  |  |  Retrieve  ]  [  Delete  | 


Status:  Login  successful. 


Figure  7.  Targeteer's  console. 


The  operational  scenario  described  here  afforded  us  a  rich  set  of  use  cases  to  exercise  our 
approach.  We  successfully  demonstrated  capabilities  to  control  access  via  policies  for  both  an 
entire  service  and  individual  service  operations,  to  assign  and  revoke  delegations-of-authority, 
and  to  handle  both  user  and  software  agent  web  service  requests. 

3.1  Technical  Details. 

To  further  illustrate  our  technical  approach,  we  present  salient  details  of  the  access  control  and 
delegation-of-authority  mechanisms  for  a  'Target’  web  service.  The  Target  web  service  is  a 
primitive  service,  i.e.,  one  which  does  not  invoke  operations  of  another  web  service.  It  implements 
Create,  Retrieve,  Update,  Delete  (CRUD)  operations  on  a  target  object.  We  suppose  that  such  a 
service  exists;  our  objective  is  to  ensure  that  only  personnel  serving  in  a  ‘Targeteer’  role  have 
access  to  these  operations. 

To  enable  access  control,  the  Target  service  must  be  associated  with  the  Access  Control  Service 
(ACS).  The  ACS  is  implemented  as  a  JAX-WS  Handler.  A  simple  way  to  link  the  web  service  to  the 
ACS  is  to  use  the  "@HandlerChain”  annotation  and  specify  the  ACS  as  the  only  handler.  The  WSDL 
document  is  augmented  to  identify  those  operations  which  will  be  enforced  by  KAoS  policies.  The 
WSDL  element  corresponding  to  the  CreateTarget  operation  is  shown  in  Figure  8.  A 
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"liftingSchemaMapping"  attribute  of  the  Security  Annotations  for  WSDL  (SAWSDL)  schema 
[SAWSDL]  has  been  added.  The  purpose  of  this  attribute  is  to  identify  an  Extensible  Stylesheet 
Language  (XSL)  file  that  maps  the  web  service  vocabulary  to  that  used  by  KAoS.  This  is  a  powerful 
mechanism:  It  allows  the  KAoS  policy  and  domain  ontologies  to  develop  and  evolve 
independently  from  the  web  service  schema.  The  associated  XSL  mapping  file  is  provided  in 
Figure  9.  In  this  case,  only  a  simple  translation  is  needed  to  map  the  web  service  operation 
requested,  CreateTarget,  into  the  KAoS  domain  concept,  CreateTargetAction.  In  general,  the  web 
service  operation  and  its  parameters,  and  possibly  parameter  values,  may  require  transformation. 


<xsd: element  name="CreateTarget" 

sawsdl : lif tingSchemaMapping="CreateTarget20nt . xslM> 
<xsd : complexType> 

<xsd: sequence> 

<xsd: element  ref="dm: Target"  /> 

</xsd: sequence> 

</ xsd : complexType> 

</ xsd : element> 


Figure  8.  A  portion  of  the  WSDL  definition  for  the  create  target  operation. 


<xsl : stylesheet  version=" 1.0" 

xmlns : xsl="http : //www. w3 . org/1999/XSL/Transform" 
xmlns : rdf="http : //www. w3 . org/1999/02/22-rdf-syntax-ns#" 
xmlns : ns2="http : / font . ray . com/Targe tService/" 
xmlns : java="http : //xml . apache . org/xalan/ java" 
exclude-result-prefixes=" java"> 

<xsl : template  match="ns2 : CreateTarget" > 

<rdf : Description  rdf : about=" REPLACE -WITH-KAOS-URI "> 

<rdf : type 

rdf : resource="http : //ontology . ihmc . us/TargetAction . owl#CreateTargetAction" /> 
</ rdf : Description> 

</xsl : template> 

</xsl : stylesheet> 


Figure  9.  The  XSL  Stylesheet  that  specifies  a  mapping  between 
the  CreateTarget  web  service  request  and  KAoS  ontology. 

When  the  Target  web  service  is  initialized,  the  associated  instance  of  the  ACS  is  instantiated.  This 
ACS  reads  the  WSDL  and  XSL  files,  and  then  creates  a  XSL  Transformations  (XSLT)  transformer  for 
the  CreateTarget  request.  It  also  initializes  a  KAoS  Guard  that  will  be  responsible  for  applying  the 
authorization  policies.  Subsequently,  whenever  a  CreateTarget  request  occurs,  the  ACS  intercepts 
it.  The  requestor’s  identity  is  extracted  and  the  XSLT  transformer  is  applied.  The  resulting  data  are 
used  to  construct  a  call  to  the  KAoS  Guard  to  determine  if  the  request  is  authorized.  The  KAoS 
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Guard  applies  the  relevant  policy.  In  simple  terms,  this  policy  states:  "Any  Targeteer  is  authorized 
to  perform  a  CreateTargetAction  which  has  any  attributes."  If  the  requestor  has  been  assigned  the 
Targeteer  role,  then  the  request  is  allowed  and  the  handler  forwards  it  to  the  Target  web  service. 
If  not,  an  exception  is  raised  and  no  further  request  processing  occurs. 

We  note  that  the  Delegation  service  is  designed  in  the  same  manner;  however,  its  operations 
require  more  sophisticated  interaction  with  KAoS.  Like  other  web  service  operations,  the 
delegation  operation  itself  is  controlled  by  policy.  The  associated  XSL  file  for  the  delegation-of- 
authority  operation  is  shown  in  Figure  10.  It  defines  transformation  rules  that  map  both  the 
operation  (DelegateRole)  and  parameters  (delegatedRole,  delegateeld  and  delegationContext)  to 
their  ontology  equivalents. 


<xsl : stylesheet  version=" 1.0" 

<xsl : template  match="ns2 : DelegateRole "> 

<rdf : Description  rdf : about=" REPLACE -WITH-KAOS-URI "> 

<rdf : type 

rdf : resource="http : //ontology . ihmc . us/DelegationAction . owl#DelegationAction" /> 
<action : hasDelegatedRole  rdf : resource=" { delegatedRole } " /> 

<action : hasDelegee  rdf : resource=" { delegateeld} " /> 

<action : hasDelegationContext  rdf : resource=" {delegationContext} "/> 

</ rdf : Description> 

</xsl : template> 

</xsl : stylesheet> 


Figure  10.  XSL  file  for  mapping  a  delegation  web  service  request. 

There  are  several  policies  that  apply  to  delegation  operations.  One  such  policy  states:  “Any 
SeniorlntelligenceDutyOfficer  is  permitted  to  delegate  the  Targeteer  role  to  any 
IntelligenceOfficer.” 

Unlike  other  web  service  operations,  whenever  a  delegation  operation  is  permitted,  the 
credentials  of  the  associated  delegatee  must  be  modified.  This  is  accomplished  through  calls  to  the 
KAoS  API  that  modify  ontology  instance  data.  For  example,  the  invocation, 
delegateRole(“Targeteer”,  “baker”,  null),  adds  a  “hasDelegatedRole”  property  with  the  value 
"Targeteer”  to  the  "baker”  instance  of  an  "IntelligenceOfficer".  Each  such  role  delegation  is 
identified  by  a  unique  Uniform  Resource  Identifier.  Later  revocation  operations  reference  this 
identifier.  Revocation  operations  make  changes  to  both  the  ontology  model  and  the  global 
Credentials  repository;  therefore,  revocation  of  delegation  is  immediate. 

4.  Summary 

We  have  built  a  demonstration  system,  based  on  scenarios  from  an  air  operations  center,  which 
utilizes  KAoS  to  govern  delegation  of  authority  in  the  context  of  web  service  access  control.  We 
discussed  the  architecture  of  our  demonstration  system,  described  the  mechanisms  for 
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authorization  of  delegation  actions  and  web  service  requests,  and  showed  how  KAoS  integrates 
with  existing  standards  for  web  service  modeling,  implementation  and  security.  A  powerful 
feature  of  our  approach  is  that  it  can  be  applied  to  existing  web  services  with  little  or  no 
modification  of  service  implementation.  It  also  allows  the  schema  used  for  web  service  design  to 
evolve  independently  of  the  policy  and  domain  ontologies.  Future  work  will  focus  on  developing 
tools  for  automatically  generating  the  necessary  transformation  files,  more  fully  supporting 
composite  and  orchestrated  web  services,  and  extending  the  delegation-of-authority  micro-theory 
to  incorporate  more  concepts  and  relationships  from  the  Air  Operations  Center  domain. 
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Objectives 


•  Design,  develop,  and  demonstrate  a  delegation  of 
authority  access  control  service  for  Service  Oriented 
Architectures  (SOA) 

o  Capture  delegation  policies  in  a  semantic  model  from  which 
delegation  policies  can  be  specified 

o  Develop  delegation  policy  enforcement  mechanisms 

o  Maximize  interoperability 

o  Minimize  impact  on  existing  services 

o  Demonstrate  capability  in  an  operationally  relevant  scenario 
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Operational  Context 


p  Service  Orchestration 


Service  A 


Service  B 


Service  C 


Service  D 


Service  Access 
Request  (B  >  X) 


Service  X 
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Technical  Approach 


o  Assumptions 

*  Authentication  is  handled  separately  from  authorization 


o  ...but  authentication  info  carried  in  X.509  certificate 

x  Delegation  of  authority  is  role-based,  but  could  have  contextual 
constraints 

o  Capture  delegation  policies  in  a  semantic  model  from  which 
delegation  policies  can  be  specified 

x  Define  ontologies  that  model  operational  domain,  access  control 
policies  and  delegation  of  authority  policies 

x  Utilize  KAoS  policy  language 

o  Develop  delegation  policy  enforcement  mechanisms 

x  Utilize  KAoS  policy  engine 
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Technical  Approach 


o  Maximize  interoperability 

*  OWL  for  semantic  modeling 

*  WSDL  for  web  service  description 


o  Minimize  impact  on  existing  services 

x  Where  possible,  restrict  access  control  specifications  to  web 
service  interface  components 

x  Place  run-time  code  for  policy  enforcement  in  handlers 
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About  KAoS 
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Semantic  Model:  Using  a  Foundational  Ontology 
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Semantic  Model:  Delegation  Entity  Relations 
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Demonstration  Architecture 
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Authorization  Control  Flow 
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Extract  invocation  elements 
Convert  to  ontology  terms 
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Example 


601st  Air  Operations  Center 
Combat  Operations  Division 


Welcome  smith.  Logout 

Delegation  Management  Console 

Current  Delegations 


User 

Delegated  Role 

Action 

baker 

TargeteerRole 

Revoke 

Select  User 

v  Select  Role 

d| 

Delegate 


Status:  http:  ontology.ihmc .us  \liHtanr  \IilitanrEntit>r.owl=T argeteerRole  delegated  to  umKAoS=baker 


The  Delegation  web  service 
implements  role  delegation 
operations 

Objective  is  to  ensure  that  only 
personnel  serving  in  ‘Senior.. .Officer’ 
roles  have  access  its  operations 

KAoS  policy  created  using  KPAT 

“Any  Senior IntelligenceDuty Officer  is 
permitted  to  delegate  the  Targeteer  role 
to  any  IntelligenceOfficer  ” 
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Future  Work 


•  Develop  tool  for  automatically  adding  SAWSDL 
annotations  (prototype  exists) 


•  Extend  and  refine  micro-theory  of  delegation-of- 
authority 

•  Enhance  usability  of  KPAT  to  aid  in  construction  of 
more  sophisticated  policies 

•  Make  architecture  more  flexible  so  other 
authentication  mechanisms  are  easily  integrated 
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Backup  Slides 
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Demonstration  Scenario 
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Semantic  Model:  Delegation  Entity  Types 
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DelegateRole  Implementation  Details 


//  convert  KAoS  MilitaryRole  term  represented  by  delegated  role  parameter  to 
//  corresponding  KAoS  MilitaryActor  term 

delegatedRole  =  delegatedRole.substring(MilitaryEntityConcepts.MilitaryEntityOwlURL().length()); 
delegatedRole  =  MilitaryActorConcepts.MilitaryActorOwlURL()  +  delegatedRole; 
delegatedRole  =  delegatedRole. substring^,  delegatedRole. indexOf("Role")); 

//  obtain  handle  to  KAoS  Actor  associated  with  delegatee 

QueryRegistration  myQueryRegistration  =  CSIFactory.getQueryRegistration(); 
KAoSAgentDescription  myDelegateeActor  =  myQueryRegistration. getActor(delegateeld); 

//  add  new  Actor  type  to  delegatee 

myDelegateeActor.addEntityOntologicalType(delegatedRole, 

//  record  delegated  action 

myDelegationActionID  =  (String)  mySOAPMessageContext.get("actionld"); 
ActionlnstanceDescription  action  =  (ActionlnstanceDescription)mySOAPMessageContext.get("action"); 
delegationRepository.put(myDelegationActionlD,  action); 


Unlike  domain  web  services,  the  Delegation  service  modifies  ontology  instance 
data  maintained  by  KAoS 


Delegation  of  Authority  Using  KAoS 


WSDL  Modifications 


<xsd :  element  name  =  rrDel ega t eRol e rr 

sausdl :  mo  del  Ref  ere  nee  =  "ht  fcp:  //ontology.  iJimc.  us/Beieg'e  tioji.  owltfBeleg-a  tionAc  fcioii" 

sausdl : 1 if t ingSchemaMapp ing= "Bel eg-a  t eRol e20n t . xsi "> 

<xsd: complexType> 

<xsd: sequencer 

l*nA/WVVVAAA/VAAAA*AA>>AAA/VWVJ 

<xsd: element  name=  "del  ega  t  eeld  n  type=  "xsd:s  trlng"  /> 

<xsd:  element  name  =  "del  ega  t  edRol  e  n  type=  "xsd:s  trlng"  /> 

<xsd: element  name=  "del  egatl  on  Centex  t rr  type=  "xsd:s  tring"  /> 

</xsd: sequence> 

/V^vVvVvVvVvVvVv\".-VvVvVvVvVvV-. 

</xsd: complexType> 

</xsd: element> 

MVvVvVvVvVvVvVvVvVvVvVvVvV-. 


•  SAWSDL  (Semantic  Annotations  for  WSDL  and  XML  Schema)  is  a  W3C 
Recommendation  for  mapping  WSDL  components  to  ontology  models. 

•  Here  we  use  it  to  define  an  XSL  file  that  contains  the  translation  rules  for 
mapping  the  DelegateRole  service  operation  to  our  policy  ontology. 
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Delegation  Service  Annotation 


@WebService( 

endpointlnterface  ="com.ray.ont.delegation.DelegationService", 
targetNamespace="http://ont.ray.com/Delegation/", 
serviceName="DelegationService",  portName=,,DelegationServiceSOAP", 
wsdlLocation=7WEB-INF/wsdl/delegation.wsdl" 

) 

@HandlerChain(file  =  "/resources/handlerchain.xml") 

public  class  DelegationServicelmpI  implements  DelegationService 

{ 

} 


@HandlerChain  used  to  associate  web  service  with  JAX-WS  Handler  that 
contains  KAoS  Guard  for  performing  policy  checking 
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DelegateRole20nt.xsl 


<xsl : stylesheet  version= "i . 0 " 

xmlns  :  xsl=  rr 1 1 p :  //wtw.  w3  .  or  g/ 199 9/XSL/ Tr  ans  f  orm rr 

xmlns  :  rdf  =  "h  t  fcp :  //wtvtv\  w3  .  or g-/l  9 9 9/ 02/ 22 -rdf -syn  t  ax-ns# rr 

xmlns  :  action=  "h  t  tp :  //on  t  ology .  i  hmc .  us  /Del  ega  tlonAc  t  ion .  owl #  " 

xmlns :ns2= "h t tp: //on t . ray. com/ Delegation/" 

xmlns  :  j  ava=  rrh  t  tp :  //jonl  .apache,  org/xal  an/j  ava rr 

exclude-result-pref  ixes=  rrj  ava  "> 

<xsl :  template  match=  :  Del  ega  t  eRol  e  "> 

<rdf  :  Descr  ipt  ion  rdf  :  about  =  "REPLACE -WZTH-KAOS-URZTT> 

<r df  :  type  rdf  :  r esour ce=  "h ttp: //ontol ogy.  i lime .  us/Del ega 1 1  onActl on .  owl#BelegationAction "/ > 
-faction:  hasDe legatedRo le  rdf  :  resource=  tedRole}  "/> 

-faction: hasDelegee  rdf : resource= "{cielegafc eeZd} "/> 

<action: hasDelegat ionContext  rdf : resource= "{delega tionCon t ext } "/> 

</rdf :  Description 

</xsl : template> 

</xsl: stylesheet> 


Mapping  rules  specify  how  service  operation  parameters  are  mapped  to 
ontological  terms 
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